Batch Collections Processes

Navigation: Closed Tax > Accounts Receivable > Batch Collections

Description

Batch collections is the primary means by which Aumentum Tax exchanges payment information with external sources. The batch processes are usually performed using a flat file. Most of these files and processes require some sort of validation before the payments can be applied. The batch collections processes follow the Flag Payment Rule(s) and Partial Payment Rule(s) specific to each process as set up in Aumentum Cashiering.

Use the main batch collections screens to edit, schedule, and run batch collections payment import and data export processes. Use the batch collections setup screens to map and configure flags, categories, and processes used in the Batch Collections exports.

Steps

  1. On the Manage Batch Collections Process screen, click Edit for an item in the grid.

    Processes do not require unique names, but using a distinguishable name makes it easier to manage your processes.

    The Tax Data Export for eGov is an export process that does not generate a file. Instead, the process performs the export by means of populating several temporary tables.

    If you want to make changes to the parameters or steps for any batch collection payment import or data export process, contact your Aumentum Support representative.

    If you want to have a new batch collection payment import or data export process created, contact your Aumentum Support representative.

    For most processes listed, a file configuration is required. To update or create a new file layout, see Input/Output File Configuration.

  2. If the Process name is changed, click Save in the Command Item bar.

  3. Click Previous to return to the Manage Batch Collections Process screen to select another process to edit, run, or schedule.

    4. The status of an import process is set automatically to Inactive when complete. This is the norm unless it is the very first time you have run a process. You cannot continue until the status is once again Active.

      The Reactivate and Reverse buttons are only available when the status of a process is Inactive.

      • Click Reverse to reverse all payments in the most recent process. A confirmation pop-up displays.

        NOTE: To disable the Reverse button, set the Tax Accounts Receivable Allow reverse on batch collection payment import application setting to False (clear the checkbox in the Setting Value column).

        • Click OK to reverse all payments from the previous session for this process. Or, click Cancel to cancel the reverse.

        IMPORTANT: The purpose of the Reverse process is correct a payment import file when the mistake is found immediately. Otherwise, if additional transactions have been performed after the import process transactions, a reversal could corrupt the data.

      • Click Reactivate to reset the status to Active. The process must have an active status before you can run or schedule it.

        • IMPORTANT: Once a process has been reactivated, it cannot be reversed.

Batch Collections Process Details screen

Each row in the Process Schedule panel lists an individual step within the import process as a whole. Each step must be run or scheduled individually. As each step completes, its status is updated in the panel.

    1. In the Process Schedule panel, click Run for the Set Input Parameters process step.
    2. On the Batch Collections Process Parameters screen, enter the required information.
    3. Click Save in the Command Item bar.
      • Click Previous to return to the Batch Collections Process Details screen. The status of the upload is automatically updated.

    This step cannot be scheduled. It copies the file to the correct location on the server.

    1. In the Process Schedule panel, click Run for the Upload File process step.
    2. On the Upload File screen, click Browse to locate the file you want to use.
    3. Click Upload File in the Command Item bar.
    4. Click Previous to return to the Batch Collections Process Details screen. The status of the step is automatically updated.

    This step cannot be scheduled. It translates the file information into a temporary table and performs initial data validation checks.

    1. Click Run to open the Monitor Batch Process screen on which you can view the process results of the import. Verify that it completes without errors.
    2. Click Close to return to the Batch Collections Process Details screen. The status of the step is automatically updated.

    This process cannot be scheduled.

    1. In the Process Schedule panel, click Run for the Verify Total process step.
    2. On the Verify Amount screen, review the amounts for accuracy. Depending on the process, the Tender Amount is optionally entered in Step 1 - Set Input Parameters, or obtained from summing data in the file.
    3. Click Previous to return to return to the Batch Collections Process Details screen. The status of the step is automatically updated.

    This process can be scheduled. It reports on what will happen when the final Run Process step is done.

    1. In the Process Schedule panel, click Run to run immediately, or Schedule to schedule the Validate Process process step. When the process completes, the status of the step is automatically updated.

      2. NOTE: You should not schedule the Run Process within the same time interval as Validate Process.
    1. In the Process Schedule panel, click Run to run immediately, or Schedule to schedule the Run Process process step. When the process completes, the status of the step is automatically updated.

    2. When completed, the status of the overall process is automatically changed to Inactive.

      • The Reactivate and Reverse buttons are displayed in the task bar.

File Chunking

Based on configuration, you can import and validate chunks of payments from a payment file concurrently, rather than the entire file being processed consecutively. The chunks can run concurrently on different physical servers, or on the same machine with multiple batch services configured.

NOTE: The setting to allow chunking is defined in the bootstrap file implemented by your Aumentum Implementation team.

  • Most payment file data, if configured, will take precedence over any parameters entered on the Set Input Parameters process step.

  • The Validate step on the Batch Collections Process Details screen initiates a validation process for the whole payment file to identify (and remove, if configured) rejected payments early in the process. When selected, a checkbox called Create file for rejected payments available on some Batch Collections Process Parameters screens generates a file of any rejected payments using the same layout as the original file. The process reports show both results and errors.

  • Alternatively (if configured), rejected payments may be placed into a holding suspense-surplus to be researched and managed through Aumentum later.

  • The import file layout may include full paid by information based on your configuration.

  • Also based on configuration, an exception identifier Suspense Exception and exception reason Suspense Exception Reason in the file may be defined for surplus. If the payment is designated with these fields, it goes to surplus; otherwise, it is applied to the PIN/bill. If the Suspense Exception Reason is valid, and a surplus is created from that payment record, then that reason is used as the Surplus Reason Code. To accommodate this, the Suspense Rejection Reason Code systype accepts user-entered systypes; however, Batch Collection Payment Imports do not perform any validation for user-entered systypes. These systypes are used by the county in the Suspense Exception Reason process field. The Set Up Suspense screen (Tax > Accounts Receivable > Setup > Suspense Setup) accommodates this also and displays the Systype ID and whether the systype was user created. If so, a User checkbox next to the systype is selected to indicate this.

  • The batch collection Run Process step updates the record count while the task is running.

  • Batch collection payment imports can be configured to use specific process fields to include payment images. Contact the Aumentum Support team for configuration details.

  • Payment Import processes use the Aumentum Attachment feature for payment image importing, storing, and viewing.

  • Each Batch Collections import process during the Validate Process and Run Process steps generate a report when complete. The report is available on the Monitor Batch Processes screen (via Info Center > Batch Processes). Click on a batch import or export process to open the View Batch Process Details screen, from which you can select the report for viewing/saving, and if generated, the error log.

  • The following payment imports will accept payments toward payment plans. For these processes, Aumentum recognizes that a bill is in a payment plan, and applies the payment according to payment plan processing, rather than tax bill processing. Aumentum uses settings from the plan to perform some validation. (For example, partial payment is not allowed on plan installments, or partial payment is allowed on future installments only.) If the payment is rejected because it is not allowed to be applied, the Suspense Rejection Reason Code of Payment Not Allowed Due to Plan Settings will appear on the report. Aumentum also validates that the plan is in good standing before accepting payment and has a plan status of Waiting for Down Payment or Active.

    • Daily IVR Payment Import
    • Daily Remittance Payment Import
    • Daily Web Payment Import
    • eGov Payment Import
    • Lockbox Payment Import
    • MultiPay Remittance Payment Import
    • MultiPay IVR Payment Import
    • MultiPay Lockbox Payment Import
    • MultiPay Web Payment Import

  • Any payment plan information, including PIN and payment plan number, are also included in the Batch Collections Report and error log, if applicable.

  • During the Validate Process and Run Process steps, the Batch Collections Error Log is produced as the process runs to note any irregularities. It shows the run date, PIN, amount, and reason. For example, when a rejected payment is put into surplus, the reason for the rejection is reported, along with the surplus subcode created (if suspense for rejected payments is configured). For example: "Invalid Revenue Object, Suspense surplus created" or "Pmt on Tender Type not allowed due to Flag – Bill 2013-2013123456 (Flag(s): No Checks due to NSF) - Suspense surplus created". If the reason for the rejected payment is due to a Flag Payment Rule, the message will list the relevant flag.

  • For jurisdictions with TT/TDT accounts, when a Trust Tax bill is paid in full through the batch payment import (e.g., Web/IVR, LockBox, etc.), Accounts Receivable calls a Business Revenue Application Programming Interface (API) so that the Business Revenue module can update the Revenue Object Status from Filed to Paid on the Trust Tax Return.

  • When set to True, the Apply final plan payments in batch collections to bills in plan application setting will pay the charges on the bills in the plan, applying both the payment from the batch collections and any surplus (plan payments held in surplus or plan credit surplus) related to the plan toward the charges using the Payment Allocation rule associated with the plan.

    • NOTE: This application setting is only relevant for plans where the Plan Type is configured to Apply Payments as Hold plan payments in surplus.

  • When set to  False, the Apply final plan payments in batch collections to bills in plan application setting will place the final plan payment into surplus and will change the Plan Status to Paid. This application setting is only relevant for plans where the Plan Type is configured to Apply Payments as Hold plan payments in surplus.

  • For payment imports other than Lender Payment Import, the Paid by information is created based on the following information in the file:

    • If MortgageCd and LenderCd both are valid, then MortgageCd is the PaidBy and LenderCd is the PaidOnBehalfOf.

    • If only MortgageCd is valid, then MortgageCd is the PaidBy and nothing is created for PaidOnBehalfOf.

    • If only LenderCd is valid, then LenderCd is the PaidBy and nothing is created for PaidOnBehalfOf.

    • If neither MortgageCd nor LenderCd are valid, then Name fields (Paid By Name 1, Paid By Name 2, Paid By address, etc.) create the PaidBy information and nothing is created for PaidOnBehalfOf.

    • If neither MortgageCd nor LenderCd are valid and no Name fields exist, then the default configuration functionality is used.

  • The Tax Accounts Receivable Do PIN translation for Remittance Import application setting also applies to the Remittance Data Export and the Daily Remittance Payment Import (aka Remittance Payment Import).

  • Except for Lender and MultiPay payment imports, each payment line is a separate financial transaction, enabling each payment to have its own reason code.

  • An instance of the Delinquent Data Export process called Delinquent File Export #2 is available. It works like the Delinquent File Export process, except that when a delinquent group is selected as a basis for the delinquent export, other parameter criteria (tax year, minimum amount, collection type, roll caste) are ignored. Formerly located under Accounts Receivable Batch Collections, both are now available under Tax > Delinquent > Delinquent File I/O > Delinquent File I/O Export.

    • SETUP: Click Configuration > File Input/Output > Input/Output File Configuration. On the Manage Input/Output File Configuration screen, click Edit for Delinquent File Export #2 in the Saved File Layouts panel to manage file input/output file details.

Process Types

  • AR Data Export for Payments – Exports information about bills (PIN, Bill #, amounts due including breakdown and multiple due dates, optional extra rows for special assessments, TAG, Legal Party, address, etc.) in a specific configured flat file format. Known as the ‘ITAT’ export in some jurisdictions.

  • Business Account Payment Import – Imports business revenue account payments based on a business account identifier with payment information including, for example, amount, batch number, business account/date, paid by information (name, address, etc.), and payment date.

  • Daily IVR Payment Import – Integrated Voice Response (IVR) is used by certain jurisdictions as a convenience to tax payers allowing them more venues for making their property tax payments. After the IVR system has received payment, a file is generated and fed into Aumentum to create the actual payments.

  • Daily Remittance Payment Import (aka Remittance Payment Import) – High-speed remittance payments are payments collected using high-speed payment processing equipment. This equipment is designed to quickly gather payment information from hard copy bills and checks, and (optionally) to capture images of the checks used for payment. The information gathered from the hard copy bills and checks is stored in a file, along with identifying information regarding the check image. The file is fed into Aumentum to create the actual payments.

  • Daily Web Payment Import – Web payments are used by certain implementations as a convenience to tax payers allowing them more venues for making their property tax payments. Tax payers can pay taxes over the Internet. After these payments have been collected, a file is generated and fed into Aumentum for the creation of the actual payments.

  • eGov Payment Import – This import file provides detailed payment information for payments made via eGov (Public Access), including tax sale payments. The tender mappings used in this import process are set up on the Tender Type Mappings screen. Imported payment information is written similarly to payments made through Aumentum. Optionally, when a payment is made via eGov, the property can be flagged that there is a Payment Pending to provide notification or processing of overlapping payments. The flag indicating pending payments via eGov is removed as part of the import process.

    NOTE: Payment Plan and regular tax bill payments can be processed within the same payment file for eGov, Multipay and certain other imports, requiring BillNumber and TaxYear to be part of the file layout configuration.

  • eGov Tax Data Export (aka Tax Data Extract for eGov) – An extract data process that allows for exporting revenue object data to eGov (Public Access). The data made available through this process is stored in several temporary tables, which are also accessible by eGov (Public Access). This process allows for off-line access to the revenue object information. The norm is to use online “live” connection in which case Public Access makes use of APIs to reach into Aumentum and retrieve real-time data.

    NOTES:

    • This export contains detailed information about a property. It may include information about Motor Vehicle payments, or real property payments, from various systems, such as the jurisdiction's Department of Motor Vehicles (DMV). This export could include, for example, vehicle plate numbers and registration fees.

    • Optionally (if configured), during a live connection, if a payment is made against a PIN through eGov, a flag is placed on the revenue object to indicate the pending payment via eGov. This flag is removed the next time the eGov payment import process is run.

    • Some of the tables contain data about Special Assessments. The eGovNSAFnclInst_T includes a Pay Off Date column for the special assessment. The eGovNSAUDFData_T has a format of Revenue Object ID, Special Assessment ID, and UDF Code (instead of Object Type and Object Id used elsewhere in Aumentum).

    • The Tax Accounts Receivable eGov Export future amount logic application setting provides the options to set parameters for exporting future amounts and to define the Current Year setting.

    • Lender and Service Company codes associated to a Revenue Object are included in the export.

    • On the Batch Collections Process Parameters screen, you have the option to exclude inactive PINs.

    To accommodate logging of activity, two Tax Accounts Receivable application settings were created:

    • eGov extract logging on to enable logging

    • eGov extract – days to retain data to define the number of days the logging data is retained.

      • To set this up:

      1. Click Configuration > Application Settings > Maintain Application Settings.

      2. Set the setting type to Effective Date and the filter by module to Tax Accounts Receivable.

      3. Click Edit on the eGov extract logging on application setting and set it to true (default) to enable logging. Click Apply.

      4. Click Edit on the eGov extract - days to retain data application setting and define the number of days to retain the logging data (default is 30). Click Apply.

      5. Click Save in the Command Item bar.

    • To verify an in-progress extract or to use historical reporting, the following SQL statements can be used.

      1. exec PDCheckEGovProgress (no parameters). This method reports on the current (or most recently completed) export.

      2. exec PDCheckEGovProgress -1. With a parameter of -1, this method provides high-level summary information for all logged extracts.

      3. exec PDCheckEGovProgress nnnnn (where nnnnn equals the specific batch process ID). With a parameter of a specific BatchProcessId (which can be found by running method #2), this method reports on a specific instance of the export, and can be useful for comparing how specific steps have performed over time.

  • IVR File Combined Bill Export – Integrated Voice Response (IVR) is used by certain jurisdictions as a convenience to tax payers for paying taxes. The IVR File Combined Bill Export batch process exports information about bills to be paid. 'Combined’ refers to how California jurisdictions must combine Defaulted Secured bills and report a single amount due for the set.

  • Lender Data Export – The main purpose of this export is to notify the lenders of what is due on properties they service. This flat file contains basic charge and balance due information as well as other information such as owner name, valuations, and deduction information. The fields in this export are not hard coded, so the fields included may vary by jurisdiction and can be modified through Manage File I/O. Not all of the available fields are required for lenders to determine what they should pay.

  • Lender Payment Import – The Lender Payment process begins with the Lender Data Export, which is sent to all applicable lenders. Each lender chooses which properties they wish to pay and generates their own file, laid out as specified via Manage File I/O system. This file is sent to the county and contains a list of properties/payments that the lender wants to make, accompanied by a check or direct wire transfer to cover all of the properties/payments in the file. This file is then imported into Aumentum via the Payment Interface System, using the Lender Payment Import process.

    The Lender Payment Import batch collections process can recognize when a file contains payments from more than one lender or service company; and it retains the information for the specific lender or service company that paid each PIN. Select either Lender or Service Company from the Lender/Service Company type drop-down list. Then, select the specific associated lender or service company from the Lender/Service Company drop-down list. If there are multiple lenders or service companies associated with the lender or service company type, the one you select is the override if the information is not within the file. The lender or service company selected in the parameter becomes the Paid By. If the file contains a Lender Code, then Paid On Behalf Of is populated with that lender’s information.

  • Lockbox Payment Import – A bank or financial institution can collect payments on behalf of the county and create a lock box payment file. This file is then sent to the county as a flat file for import into the tax system.

  • Miscellaneous Payment Import – Not used in all jurisdictions, this process imports miscellaneous payments. The file I/O currently consists of only two fields, the Miscellaneous Source and the Amount.

  • Motor Vehicle Payment Import – Not used in all jurisdictions, this import file imports any motor vehicle payments directly from the Department of Motor Vehicles (DMV).

  • MultiPay – These batch processes import payments using a format that allows for multiple tenders toward multiple bills. For example: two checks pay five bills, or three checks pay one bill. The following types of MultiPay processes are available:

    • MultiPay Remittance Payment Import

    • MultiPay IVR Payment Import

    • MultiPay Lockbox Payment Import

    • MultiPay Web Payment Import

    Configuration of MultiPay imports requires configuration for the Tender records in the file. Set this up via Configuration > File Input/Output > Input/Output File Configuration. On the Manage Input/Output File Configuration screen, locate each MultiPay type and click Edit for each one to open the Manage Input/Output File Details screen. Select the Define Tender Detail checkbox and define the details as applicable. Click Save in the Command Item bar.

  • Remittance By Installment Export – Not used in all jurisdictions. Similar to the Remittance Data Export, but instead of exporting one row of information per bill, the export contains one row of information per installment.

  • Remittance Combined Installment Export - Not used in all jurisdictions. It contains balance due and other information about bills. The file is input into a high-speed remittance processing system and that system uses the information to determine which taxes have been paid and which taxes are still due when the bill stub and check are read. If a payment has already been made, the remittance processing system usually "kicks out" the payment and the county returns the payment to the payer. 'Combined’ refers to how California jurisdictions must combine Defaulted Secured bills and report a single amount due for the set. This export also optionally contains variables for an ‘alternate amount’ due, depending on the date of payment.

  • Remittance Data Export – This is also known as a "hot file." It contains balance due and other information about bills. The file is input into a high-speed remittance processing system, and that system uses the information to determine which taxes have been paid and which taxes are still due when the bill stub and check are read. If a payment has already been made, the remittance processing system usually "kicks out" the payment and the county returns the payment to the payer.

  • Remittance Payment Combined Installment Import – Not used in all jurisdictions. 'Combined’ refers to how California jurisdictions must combine Defaulted Secured bills and pay them together as a set. High-speed remittance payments are payments collected using high-speed payment processing equipment. This equipment is designed to quickly gather payment information from hard copy bills and checks, and (optionally) to capture images of the checks used for payment. The information gathered from the hard copy bills/checks is stored in a file, along with identifying information regarding the check image. The file is fed into Aumentum to create the actual payments.

  • Tax Sales Buyer Payment Import – Not used in all jurisdictions, this import file imports various data, depending on your jurisdiction, including but not limited to:

    • Tax sale amount for the auctioned sale of a delinquent property.

    • Internet sale winning bid data.

    • Tax sale buyer payments.

    The fields vary based on the configuration of the tax sale buyer payment import and the jurisdiction. Fields may include, for example, buyer number, name and address of the buyer, and a document stamping fee. A Batch Collection Totals report is automatically generated and includes two sub-reports:

    • Tax Sale Buyer Payment Import Summary

    • Tax Sale Buyer Payment Import Statistics

    NOTE: An additional Tax Sale drop-down list is available to select the sale that is being processed for this import when the Tax Sale Allow Property to be in Multiple Secure Sales application setting is set to True. The process then looks for the tax sale item(s) in the designated sale.

    NOTE: A Use Surplus as Tender option may be available on the Batch Collections Process Parameters screen. When available, the screen accepts entry of the surplus number and includes a Retrieve Surplus selection that populates the tender amount with the surplus amount. That surplus will be used as tender to pay each of the payments contained in the file.

  • Web IVR Data Export – An exported data file for use in a jurisdictions Internet or Integrated Voice Response (IVR) system.

Riverside, California

  • The IVR File Payment Import, Remittance Payment Import, Web File Payment Import, eGov Payment Import, Lender File Payment Import, Lockbox Payment Import, MultiPay IVR File Payment Import, MultiPay Lockbox Payment Import, MultiPay Remittance Payment Import, MultiPay Web File Payment Import will accept payments against Redemption Groups (set of Defaulted Secured bills).

  • Defaulted Secured: If set to True, the Cashiering Required payment in full for Defaulted Secured application setting requires full payment on the Redemption Group (set of Defaulted Secured bills).

  • A Real Property Transfer Fee Excel Import is available to import an Excel spreadsheet of real property transfer fees. These fees are cashiered as a miscellaneous source. Import the spreadsheet via Tax > Accounts Receivable > Batch Collections. Select the Miscellaneous Payment Import process.

    SETUP: The File I/O import process must be configured with two additional fields for Miscellaneous Sources and for Amount. Contact your Aumentum Support representative for assistance setting this up.

  • The Tax Sale Buyer Payment Import in your jurisdiction updates and creates buyers as part of its process. Any errors during the create/update of buyer are available in a generated error report. The buyer payment is not processed if there are buyer errors and a Buyer Payment Import report generated as part of this process shows these payments as blank.

    SETUP:

    1. Set the Tax Accounts Receivable Reason Code for Buyer Payment Import Threshold Exception application setting via Configuration > Application Settings.

    2. Make sure the following fields are set via Tax > Tax Sale > Property Sale > Property Sale Maintenance for the import.txt file: Temp Buyer Number, PIN, and Sequence Number. The value of the fields must match the tax sale items that you want paid by this process. If the Temp Buyer Number does not exist upon import, the buyer is created; otherwise the buyer is updated. If the Temp Buyer Number and Winning Buyer Name (PIN) must match, a Buyer number not associated to legal party error is generated.

    3. Set the File I/O Configuration via Configuration > File Input/Output.

    4. You must also map the vesting type via Property Sale > Export/Import > Vesting Configuration. Otherwise, no vesting type is imported.

    Once the processes finishes without errors, the tax sale items configured in the import.txt file are paid and you can verify this via Tax > Property Sale > Property Sale Maintenance where the buyer amount displays and the buyer information is either updated or newly created.

  • The Tax Sale Buyer Payment Import process requires that you define the tender amount when processing this import for internet sale winning bid data. The tender amount must match the total in the data file. Information included in this import includes temporary buyer number, PIN, and sequence number. If a temporary buyer number does not exist, one is created; otherwise, the buyer number is simply updated. Once all processes finish without errors, the tax sale items configured in the import.txt file (Configuration > File Input/Output Configuration) are paid, and the buyers are either created or updated. You can verify this via Property Sale Maintenance. Any vesting information defined via Property Sale > Export/Import > Vesting Configuration is displayed on the Maintain Property Sales screen.

  • Based on configuration, any batch collection payment import process that allows a payment toward a tax bill can check whether the tax bill has a Penalty/Interest Cancellation Request that does not have a status of Approved or Denied.  If so, the payment is rejected and placed into surplus (per Suspense Setup configuration) with the message Payment Not Allowed Due to Penalty/Interest Cancellation.

Dependencies, Prerequisites, and Setup

IMPORTANT: All batch collection payment imports, regardless of which import it is, use a Cashiering Service. The systype Batch Payment has been created for this purpose. Click Configuration > Systypes and verify that the Effective Date for this systype is prior to the date of any payments that will be received.

Accounts Receivable

  • Batch Collections Setup – If relevant for your jurisdiction and the configuration of the batch collection imports/exports, set up the items found on this sub-menu, including:
    • Tender Type Mapping – Map the correlation between external system (eGov/Public Access or other systems) identification of tender types, and Aumentum tender types for each payment import process that will contain tender type information. Check with the Aumentum Engineering team or your Aumentum Implementation team for Public Access configuration details.
    • Third-Party Cashiering Mapping – If the jurisdiction is using Third-Party Cashiering functionality, set the default mappings used with importing data from third-party cashiering systems into Aumentum. Check with your Aumentum Implementation team for the latest information about setup requirements.

Assessment Administration

  • Value Types – Required for Batch Collections Value Type Setup mapping, if Value Type information will be exported in your jurisdiction.

Cashiering

  • Flag Payment Rules – If relevant for your jurisdiction’s business processes, set up payment rules for flagged items for each batch collection process.

  • Set Up Credit Cards and Set Up Tender Types are needed if Tender Type Mapping will be used.

  • Set Up Global Cashiering – The receipt year used for Payment Imports is the one set up in Global Cashiering.

  • Set up Tills is required for payment imports.

Configuration Menu

  • Application Settings – Specify for the application setting "Maximum Upload File Size" (setting type: effective date; module: Common) the maximum size in megabytes allowed for the import file size. In addition to A/R Batch Collection imports, the screens that use this same setting include Import Tax Bill Addresses for Mail Presort, Select Bills or Revenue Objects, and Import Lender Revenue Objects in Billing; and Management Correspondence Files in Delinquents.

    This application setting needs to accurately show the IIS limit on import/export file size. Changing this application setting in Aumentum does not change the file size allowed in IIS. IIS must be changed first and then this application setting changed to correspond to IIS. Changing it in IIS requires a system administrator or appropriate Aumentum personnel.

  • Input/Output File Configuration – Specify the file layout for the Batch Collection import or export files.

  • Flags – Set up various flags and values, such as block payments, bankruptcy flag, Chapter 7, Chapter 11, Chapter 13; Appealed flag and Appealed flag value.

Levy Management

  • Tax Authorities – Required to be set up for specific special assessments, if Tax Authority information will be exported in your jurisdiction.

  • Payment Management – Uses the payments that are imported and applied by the Batch Collections processes.

Tips

Export processes generally export data from Aumentum to flat files that are used in other applications. The WEB and IVR export files, for example, are used by a third-party vendor that manages the Web and IVR software for a county.

Imports – Entries in the import file that cannot be processed are listed in the process error report. This report also includes the date, account number, error reason, and amount for each account, along with the total number of accounts rejected and the total dollar amount for the report.

Web and IVR exports – Entries in the export file specify the most recent due date as the due date if there are no due dates that fall on or after the current date. For example, If my due dates are 1/15/19 for the 1st installment and 2/23/19 for the 2nd installment, and we run the export on 3/7/2019, the export shows 2/23/19 as the due date (since there is no due date today or in the future and 2/23/19 is the most recent due date). Note also that the due date on revenue objects that do not have a current year bill are left blank by design.

eGov exports now include options for the alternate due date and the delivery address. Also, you can enter a range of tax years; to run the export for a single year, enter the same year in both the From and To tax year fields.

All of the batch collections processes follow the flag payment rules specific to the process as set up in Aumentum Cashiering. (Suspense status does not impact the application of the rules.)